Subject: Re: MUI 2.0 bug!
From: "Stefan Stuntz" <[email-masked]>
Date: Thu, 17 Mar 1994 23:05:26 GMT
Newsgroups: comp.sys.amiga.applications,comp.sys.amiga.programmer

Christoph Feck wrote:

CF> Wrong.  MUI uses only rootclass which actually is in no way
CF> related to Intuition (the fact that BOOPSI functions are in
CF> intuition.library doesn't mean that rootclass is based on
CF> Intuition functions.

Correct. I would have loved to do all my works based on gadgetclass,
but it turned out that this class is just too silly for auto-layout
GUIs. The most important thing for such a GUI is that all their
contents to know about their min/max/default sizes before a
parent window is actually opened. This implies some kind
of setup method with environment information (fonts, etc.).
Neither gadgetclass nor any other classes distributed by
Commodore are capable of doing such things (not in V37, not
in V38, not in V39, not in V40, maybe never?), it seems noone
there ever thaught about auto-layout. These types of boopsi
gadgets are completely useless for creating automatic,
font-sensitive user interfaces.

But since there are some really nice boopsi gadgets flowing
around (colorwheel, gradient slider, etc.), I wrote
a boopsi interface class for MUI, which allows every subclass
of gadgetclass to be used as MUI object in a MUI window.
Due to the missing features of gadgetclass, there are
some drawbacks (e.g. the programmer needs to specify min/max
sizes when creating the object), but it works.

CF> MUIs area class is NOT based on gadgetclass.  Of course,
CF> this has both downsides and upsides.  I think starting with
CF> OS 3.0 it makes more sense to base such a system on
CF> gadgetclass (hint hint ;)

Sorry, I can't see any automatic layout capabilities in OS 3.0.
Maybe you could tell us a bit more about this. BTW, I don't call
GFLG_RELxxxxx flags automatic layout, I call it nonsense :-)

CF> Of course letting MUI run on the applications process isn't
CF> bad either.

It's the only way accomplish certain goals. Did you ever try to
make an intuition gadget pay attention to clip regions? Virtual
groups would be impossible with your user interface running
on several different tasks.

Yes, sometimes its nice to have input.device.task handle gadgets.
That's why the Amiga has the best "prop gadget feeling" of every
platform and that's why I decided to have MUI's prop gadgets also
handled by input.device.task. But having a complete user interface
under input.device control is simply not necessary and brings up
lots of refreshing problems.

CF> It replaces gadgetclass, which is not only the baseclass of
CF> all gadgets in the system, but also the superclass for any
CF> gadgets we have (like colorwheel, datatypes etc.), and for
CF> any gadgets we will see in the future (apart from new MUI
CF> classes :)

True. But due to MUIs boopsi interface class, all MUI applications
can benefit from new boopsi classes. Of course things would be
a bit nicer with new MUI classes... :-)

Greetings, Stefan.